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Abstract 


When not at home and in need of Internet access, one 
can search for an open Wifi access point. But if there 
is none available, you’ll have to set up a connection 
through a mobile network—GPRS, EDGE, UMTS, HS- 
DPA, or WCDMA networks. For laptops, there are spe- 
cial PCMCIA cards that can do that; most mid- or high- 
end mobile phones can do this through USB or Blue- 
tooth as well. To manage such a connection, one needs 
special software—it works differently from a regular 
phone dial-up, Wifi, or Ethernet connection. 


umtsmon was created to address this need. The au- 
thor wanted to have a simple tool that works for all cur- 
rent Linux distributions. umt smon is not the final mo- 
bile network manager application—at some point, the 
functionality of umtsmon will have to be integrated into 
Network Manager and its GUI apps. But umtsmon will 
definitely serve as a playground to find out what users 
really want, so only the really used features will be im- 
plemented the right way into Network Manager. Also: 
umtsmon is available now as a simple download and 
run—it is usable for existing Linux users. The inte- 
grated Network Manager will only help future distribu- 
tions. 


In this talk, Klaas will discuss mobile networks in gen- 
eral, how the various brands of pecards work, and what 
umtsmon can and cannot do yet. 


1 Short history of 3G networks 


For Western European consumers, mobile communica- 
tion networks started in the early 80s. Back then, most 
countries had their own analog standards and equipment 
was heavy—mainly due to the batteries and antennas. It 
was also rather easy to listen into conversations and it 
was expensive. 


The organisation GSM, Groupe Spécial Mobile, was 
started in 1982 by the joint European telecom operators 


to address the issues. By the end of the eighties, the 
GSM standard was close to finished and was tranferred 
to a standardization body, ETSI. The new standard used 
digital transmission, performed frequency hopping, and 
prevented tapping of conversations. 





The first network to go live was in Finland in 1991; by 
the end of 1993, networks were operational in 48 coun- 
tries with a total of one million subscribers. 


The popularity of GSM surprised many—by now every 
person in the Netherlands (including newlyborns and the 
elderly) owns more than one mobile handset. This un- 
expected surge in users caused telecom operators to start 
hunting for expansion of their networks—they feared 
overloading of their networks. 


Also, GSM features a direct tunnel from handset to local 
cell antenna, and users are charged for the duration of 
the connection. This is less useful for data connections, 
so an extension to the GSM standard was made: GPRS. 
This allowed for a packet-switching-based connection, 
therefore not requiring a tunnel. Charging per amount 
of data was possible. However, GSM/GPRS only allows 
for small bandwidths—typically comparable to old ana- 
log modem speeds—max 28k8 kbits/s if you are lucky. 


UMTS was created to address these two needs— 
relieving the load of the GSM networks and addressing 
higher bandwidth data communication. Different radio 
technology required new antennas, thus requiring new 
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radio frequencies and equipment. Governments across 
Europe saw their chance and auctioned the new radio 
frequencies for astronomic sums of money. Several 
telecom operators nearly went bankrupt because they 
were forced to buy into expensive frequencies in several 
countries. 


A deafening silence followed. 


UMTS requires a lot of antennas. To get a decent cov- 
erage, there are far more antennas required for UMTS 
than there are for a normal GSM network. The year 
2004 through the first half 2006 saw a heated debate on 
the dangers of radio transmitters in cell phones and an- 
tennas to the public health. All kind of research either 
suggested that one would get sick from living close to an 
antenna, or would get a heated brain from using a cell 
phone. Also some people advised against wearing a cell 
in one’s trouser pockets as it might reduce virility (?!). 
This made several local municipalities refuse UMTS an- 
tennas within their territory. These “white spots” in 
UMTS coverage might endanger the timely roll-out of 
the UMTS networks... 


So, telecom operators invested in frequencies, invested 
in equipment. And just some Internet junkies bought 
into it and bought PCCards for laptops or expensive 
phones that used the new network. At the same time, 
most operators added new GSM antennas to their new 
UMTS stations. By creating more cells, the average 
number of users in a cell decreased—the GSM technol- 
ogy was saved from overload. 


PCCards and especially Blackberries were the first killer 
apps for UMTS—these devices use UMTS (if available) 
to get their users access to their e-mail. The reduction 
of the rates helped adoption of UMTS, but still many 
consider it too expensive. Nowadays, most telecom op- 
erators are on break-even for their 3G networks—when 
not counting in payment of the original radio licenses. 


By now, telecom operators see the danger of competing 
technologies like WiMax and Wifi. So they are moving 
their UMTS networks forward to HSPA (HSDPA and 
HSUPA) which require yet new devices. 


2 Analysis of aPCMCIA UMTS card 


All telecom operators sell PCCards for laptops. How- 
ever, all are OEM products, manufactured by small 





specialised companies like Option (Belgium), Nova- 
tel Wireless (USA), 3GSystems (Germany) and Sierra 
Wireless (USA). 
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Figure 1: a PCMCIA card and its contents 


The first generation of UMTS cards as pioneered by Op- 
tion, have an interesting hardware architecture as de- 
picted in Figure 1. If one inserts the card into a laptop 
running Linux, Linux will recognize a new USB inter- 
face. Three (or four) usbserial devices are connected 
(via a hub) to that USB interface. Standard Linux ker- 
nels do not recognize the VendorID/Product ID for us- 
bserial, but if forced to load by hand, three new serial 
ports appear on /dev/ttyUSBx. 


Most other vendors have cards with similar design—this 
is mainly due to the fact that there are very limited man- 
ufacturers of chipsets for UMTS data. In most cases, 
this is QualComm. 


QualComm decided to go a different route for the HS- 
DPA cards. No longer serial2usb interfaces, but spe- 
cialised connections that require a specialised driver. 
With help from other people, Paul Hardwick from Op- 
tion ported the existing Windows driver to Linux. This 
driver is now known as the Nozomi driver. Its path to 
inclusion in the Linux kernel is interesting—of course it 
was rejected for inclusion because it was not written the 
“Linux way.” With help from Greg Kroah-Hartman, the 
driver is taking shape now. 


3 Analysis of a “Zero CD” USB UMTS brick 


To reduce packaging costs, some vendors now ship a 
technology called “ZeroCD.” It was pioneered by Op- 
tion in their ICON USB box (see Figure 2), but there 
are also PCCards available. Essential is that the device 
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Figure 2: a “ZeroCD” USB box and its contents 


boots up as a USB Mass Storage Device. For Windows 
users, an autorun.inf file will automatically take 
care of installing the software. Afterwards, the driver 
will send a magic string to the USB Hub. The USB Hub 
then disconnects the Mass Storage and connects the mo- 
dem ports, either through USBSerial or the above men- 
tioned Nozomi. For this type of device, vendors do not 
need to ship installation CDs. For users, the installation 
is simplified: just plugging it in is enough. 


The major disadvantage of the current ZeroCD chipset 
is the power consumption—it requires two USB plugs 
because one USB plug can only carry 5W...Be care- 
ful and remove the device if your laptop runs on battery 
power! 


4 Back to the AT commands era 


Whether the card supports serial or nozomi, after load- 
ing the right driver, you will run into serial ports 
on /dev/ttyUSBx, /dev/ttyACMx, or /dev/ 
nozomix. 


Adventurous Penguins immediately type minicom 
/dev/ttyUSBO to see what’s on the serial devices. 
Hopefully, they are old enough to remember the good 
old Hayes-compatible modem era, where one could play 
with AT Commands and PPP settings for ages before the 
first connection to the outside world was successful. 





Actually, they need to—because that’s exactly what you 
get: all three interfaces are connected to an UMTS mo- 
dem with an AT Command set. However, standard- 
ization committee 3GPP has standardized the AT com- 
mands for 3G network modems, so there are standard- 
ized commands to talk to the modem to enter PIN codes, 


select the network of a mobile operator, send an SMS, 
and such. There are multiple interfaces to the modem 
to allow one interface to be used by PPP for the actual 
network connection, whereas one can use another inter- 
face to send AT commands to retrieve the status of the 
modem, network, or SIM card. 


A few examples of new AT commands: 


e AT+COPS=? will (after 30 seconds) return a list of 
all mobile networks that are available, with info on 
which networks you are allowed to connect to. 


e AT+CPIN="1234" to enter a PIN code for the 
smart card. 


e AT+CSQ returns the signal strength of the mobile 
connection. 


So we’re stuck with AT interfaces. Let’s re-install ppp 
and go back to the old days. Or install umtsmon—which 
will interact with the modem and do all the AT com- 
mands for you. 


5 Single Serial Port devices 


The most popular cards in Europe all have multiple in- 
terfaces. This means that we can, for example, use 
/dev/ttyUSBO to connect PPP to, whilst we can si- 
multaneously send AT commands to /dev/ttyUSB2. 
However, some cards (like the Sony Ericsson GC79, 
most Sierra Wireless cards, and some of the Novatels) 
only have a single serial port. This means that AT com- 
mands and PPP data need to share the same port. Tech- 
nically, this is not a problem—software like kppp im- 
plements this functionality already. However, the Open- 
Moko project also spawned a new project called the 
GSM Daemon that also can do this. This might be an 
interesting road for the future—at the cost of another 
external dependency. 


6 umtsmon system design—dependencies 


As stated before, umtsmon was designed to work on as 
wide a range of Linuxes as possible. This is why we 
attempt to make as few assumptions about the operat- 
ing system as possible. Yet we have to rely on a few 
packages to be present: 
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e PPP 
We need PPP to make the actual network connec- 
tion and change routing and such. 


e QT3 
The QT library is needed for the UI. umt smon 
cannot run without it. QT in itself also has a few 
dependencies, like X. 


For versions of umtsmon beyond 0.6, we probably will 
add a few more requirements: 


e pcemcia-utils 
This one obviously is not necessary for the ICON 
and other USB-only devices. We want to use 
pemcia-utils to enable users to reset the card 
(pccard eject andpccard insert) and/or 
to simplify the autodetection code. 


e libusb 

At this moment, a lot of the autodetection is 
done by browsing through the /sys filesystem. 
This is rather complex to code consistently for 
all Linux kernel revisions. Using libusb should 
solve that problem for us and again simplify the 
autodetection code. It might be wise to move the 
libusb-dependent code into a shared library that is 
dlopen () ed at runtime to prevent umtsmon from 
trying to run if libusb isn’t present or if it is too old 
to work. 


icon_switch 

This is a small utility that switches the ICON box 
from mass storage to modem operation. Unfortu- 
nately, it is rather unreliable and it needs exten- 
sions for the other ZeroCD devices that have dif- 
ferent USB IDs and may require different code se- 
quences. umt smon at this moment requires PPP to 
be SUID—umtsmon calls pppd directly with argu- 
ments controlling the connection. umt smon will 
complain to the user if PPP is not set SUID and 
ask the user if it is allowed to fix it. This is a se- 
curity hole: in theory people could start writing 
malicious dialers dialing expensive foreign num- 
bers. This should be addressed in a future re- 
vision by having umtsmon create profiles in the 
/etc/ppp/peers/ directory. 





7 umtsmon software design 


Internally, umtsmon is written to follow the MVC de- 
sign pattern. MVC means Model View Controller. Ba- 
sically, this comes down to a separation of concerns— 
a class should only contain code that represents data 
(=model), changes data (=controller), or displays it 
(=view). 


Central in the umtsmon 0.6 design are the classes Query, 
SerialPort, ConnectionInfo, and PPPConnection. Any 
AT Command sequence that is to be sent to the card is 
represented as a Query instance. The Query class also 
contains rudimentary parsing and will strip off echos 
and such. Query connects to a SerialPort instance for 
the actual communication. 


The following paragraphs discuss some details of the 
design of umtsmon. 


7.1 PPPConnection 


PPPConnection is the beating heart of the application. 
As can be seen in Figure 3, the main GUI class Main- 
Window subscribes one of its attributes, the Main Win- 
dowPPPObserver, to receive any state changes of the 
PPP daemon. If someone outside umtsmon or umtsmon 
itself then starts the ppp daemon to make a connection, 
the PPPConnection class with call all its attached Ob- 
servers to notify the state changes. MainWindow re- 
sponds to that by enabling/disabling buttons and menu 
items. 


At this moment, only MainWindow is subscribed to re- 
ceive the PPP state changes. This will change in the near 
future when we start talking about the NetworkManager 
integration—that will require another Observer to the 
PPP state. 


7.2 (Inhibiting) ConnectionInfo 


ConnectionInfo regularly polls the card to ask for the 
mobile operator, signal strength, and such. On some oc- 
casions, ConnectionInfo must be prevented from send- 
ing out Queries, like during the PPP connection setup or 
whilst AT+COPS=? (see Section 4) is running. In such 
cases, the PPPConnection or NetworkChanger class just 
creates a ConnectionInfolnhibitor instance. Creation 
of the Inhibitor instance will increase a counter inside 
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Figure 3: Class Diagram of PPPConnection and interacting classes 
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Figure 4: Class Diagram of ConnectionInfo and interacting classes 
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Figure 5: Class Diagram of Profile and interacting classes 


ConnectionInfo; upon destruction, the counter will au- 
tomatically be decreased. PPPConnection uses an in- 
stance of the Runner class to manage the execution of 
/usr/sbin/pppd. This is shown in Figure 4. In the 
case of single serial port cards, the AT commands and 
the PPP data stream need to be sent over the same serial 
port. In that case, ConnectionInfo never can run when a 
PPP connection exists. 


7.3 Profile Management 


Refer to Figure 5 for a class diagram. Once the user 
clicks on the connect button in MainWindow, PPPCon- 
nection gets called with a reference to a Profile. PP- 
PConnection will use the info inside the Profile class 
to setup the connection. To change a profile, the user 
selects Profile Management in the menu in the GUI. 
The ProfileDialog will be instantiated and filled with 
the data from the active Profile. Users then can choose 
to create another profile, change the current one, etc. 
The data is stored to disk in a key=data formatted 
~/.umtsmon/umtsmonrc file. The QSettings class 
takes care of that. Because settings need to be accessed 
throughout the program, possibly even before main () 
is started, settings are always retrieved through a Single- 
ton pattern class. This also solves the issue that a QSet- 
tings class only saves its data upon destruction. Call- 


ing makeChangesPersistent () will thus cause 
the QSettings instance to be destroyed. 


8 NetworkManager integration and/or 
takeover 


High on the wish list is to integrate at least a little with 
NetworkManager. The big annoyance is that at the mo- 
ment, even if a UMTS connection is made, software 
like Gaim and Firefox will refuse to connect because 
according to them there is no connection. Apparently 
they use libnm to ask NetworkManager if the system 
is on-line or not. As stated before, umtsmon should 
run, regardless of NetworkManager’s presence. How- 
ever, this is only loose coupling—we’re not discussing 
adding UMTS support to Network Manager yet. In the 
end, UMTS connections should be just another item that 
is implemented in NetworkManager and its GUIs. We 
currently view umtsmon as a playing ground for that. 
What features are actually used? How to implement 
stuff? Where to put security constraints? It all is eas- 
ier to do in a small program than in the collection of 
binaries that makes up NetworkManager. Yet Network- 
Manager is the future—it is the most convenient way 
for users to manage yet another networking connection. 
It remains to be seen if the current umtsmon team will 
actually do the NetworkManager implementation. 
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Brand model type remarks 

Sony Ericsson GC79 single-port serial GPRS and EDGE only 

Option GT GPRS EDGE 

Option 3G Quad three of four port usb2serial need kernel module usbse- 
rial.ko with parameters or 
the specialised option ker- 
nel module. 

Huawei E612 

Option nozomi need nozomi kernel module 

Option ICON external usb box ZeroCD chipset, need 
switching 

3GSystems XSPlug3 

Sierra Wireless | 7xx series PCMCIA serial modem single serial port 

Novatel U630/U530 

Novatel XU870 dual serial port, only first usable | first Expresscard to be sup- 
ported 

Kyocera KPC650 dual serial port serial ports don’t communi- 
cate. 

various mobile | various connect through either serial, | handled as a single serial 

phones USB or Bluetooth port card 











Table 1: Hardware support of umtsmon 


9 Device, Commercial and Distribution sup- 
port 


At this moment, umtsmon supports a wide variety of 
hardware. The 0.6 release will support devices from No- 
vatel, 3G Systems, Sony Ericsson, Option, Sierra Wire- 
less, and Huawei. Also mobile phones that have a lap- 
top connection through USB, Bluetooth, or serial can 
be supported, with a few limitations. See Table 1 for a 
more complete list. 


None of the device vendors is cooperating with the de- 
velopment, however. The development team is currently 
investigating creating a fund to buy all available hard- 
ware and distribute it amongst the developers to ensure 
that all hardware is supported and remains operational. 


Network operator T-Mobile Germany sponsored the de- 
velopment by providing a laptop and devices to one 
of the developers, who happened to also have done an 
internship on UMTS on Linux for T-Mobile. The in- 
ternship resulted in a lot of improvements to umtsmon, 
thanks Christofer! 


At the moment of writing this paper, umtsmon is 
available as a standard package in OpenSuse (starting 
umtsmon 0.3 in OpenSuse 10.2) and Gentoo (starting 
with umtsmon 0.5, currently in ~amd64 and ~x86 only). 


10 Conclusions 


e Support for UMTS cards is in the same position as 
hardware enablement projects like ALSA were a 
few years ago. Several devices work—mostly the 
devices owned by the developers. Manufacturers 
don’t see the need to cooperate yet, nor to fund de- 
velopment. 


e All known 3G mobile devices implement serial in- 
terfaces, either directly or through drivers. 


e UMTS is just another radio technology reusing ex- 
isting communication standards: AT commands. 


e umtsmon was created to handle the AT commands 
exchange for the user and start the PPP daemon. 


e umtsmon is not really integrated into Linux—it’s a 
standalone application. 


e NetworkManager integration should start from 
scratch, possibly inheriting the GSM multiplexing 
daemon from OpenMoko to solve the single serial 
port problem correctly. 


e Writing a paper for OLS is a good stimulus for 
coders to finally write down some parts of their 
software design. 


252 e Short-term solution for 3G networks in Linux: umtsmon 
11 Links 


The umtsmon website: 
http://umtsmon.sourceforge.net/ 


PharScape (HOWTOs and support forum for all Option 
based cards and the Nozomi drivers): 
http://www.pharscape.org/ 


The 3GPP approved AT command set: 
http://www. 3gpp.org/ftp/Specs/latest/ 
Rel-7/27_series/ 





